…odealliance#11374)

* use a single table per instance for resources, waitables, etc.

Per WebAssembly/component-model#513, the spec now puts
resources, waitables, waitable sets, subtasks, and error contexts in the same
table per instance.  This updates the implementation to match.

- Combine the `ResourceTable` and `StateTable` data structures into a single `HandleTable` structure

- Rename `ComponentInstance::instance_resource_tables` to `instance_handle_tables`

- Remove `ConcurrentState::waitable_tables` and `error_context_tables` in favor of the above

- Move various associated functions from `ConcurrentState` to `ComponentInstance` so they can access `instance_resource_tables`

While I was doing table-related things, I also updated `concurrent::Table::new`
to reserve the zero handle to mean "invalid".  This won't affect what the guest
sees in any way, but it allows us to use `TableId::new(0)` to invalidate
host-owned handles in e.g. `{Stream,Future}{Reader,Writer}::close`.

Fixes bytecodealliance#11189

Signed-off-by: Joel Dice <joel.dice@fermyon.com>

Re-internalize `ResourceKind` to `mod handle_table`

Remove `ResourceKind`

Start flattening the representation of `Slot`

Internalize `get_mut_handle_by_index`

Internalize implementation details such as the representation of slots
to and make methods a bit more targeted in their functionality.

Internalize more details of `HandleTable`

Don't expose `HandleKind` and of per-function methods for operating on
the various kinds of handles that reside in the table.

Flatten the representation of `Slot`

There's still some more work to do for host/guest resource handles, but
this helps realize the goal of the previous refactorings in the
meantime.

* stop using `HandleTable::reps_to_indexes` when delivering events

Per review feedback, we'd like to get rid of `HandleTable::reps_to_indexes`
entirely.  This commit doesn't go quite that far, but now we only use it for
`error-context` handles.  For waitables, which can only be referenced by at most
one guest at a time, we now store the guest handle in `WaitableCommon::handle`
and retrieve it from there when delivering an event for that waitable.

For `error-context` handles, the spec requirement that we always lower the same
handle for the same `error-context`, combined with the fact that an
`error-context` may be referenced by more than one component instance at a time,
means we still need some general way to convert a host rep plus component index
into a handle.  Going forward, we could consider either removing that "same
handle" requirement from the spec or consider an alternative implementation
(e.g. storing a `HashMap<RuntimeComponentIndex, usize>` in the `ErrorContext`
host state for keeping track of the handles for each referencing instance.

Signed-off-by: Joel Dice <joel.dice@fermyon.com>

* remove `HandleTable::reps_to_indexes`

Turns out the spec no longer requires that guests receive the same handle for a
given `error-context` as the one they already have, so we no longer need this
field -- nor do we need to maintain a per-component-instance reference count.

Signed-off-by: Joel Dice <joel.dice@fermyon.com>

---------

Signed-off-by: Joel Dice <joel.dice@fermyon.com>